API review

Proposer: Melonee Wise

Present at review:

• Eric Perko
• Chad Rockey
• Jack O'Quin
• Tully Foote

Overview

The joy/Joy msg is currently in the joy package requiring all packages to depend on the joy package. This migration would eliminate the package dependency on joy and follow the ROS guidelines for separating out general purpose msgs in to msg packages. Additionally the joy/Joy msg lacks a header which is important for synchronization and several users have requested a header be added to the joy/Joy msg.

Proposed Messages

• sensor_msgs/Joy.msg

   # Reports the state of a joysticks axes and buttons.
  
   Header header           # timestamp in the header is the time the data is received              
                           # from the joystick
  
   float32[] axes          # the axes measurements from a joystick
   
   int32[] buttons         # the buttons measurements from a joystick 

Migration Rules

class update_joy_Joy_e3ef016fcdf22397038b36036c66f7c8(MessageUpdateRule):
        old_type = "joy/Joy"
        old_full_text = """
float32[] axes
int32[] buttons
"""

        new_type = "sensor_msgs/Joy"
        new_full_text = """
Header header
float32[] axes
int32[] buttons

================================================================================
MSG: std_msgs/Header
# Standard metadata for higher-level stamped data types.
# This is generally used to communicate timestamped data
# in a particular coordinate frame.
#
# sequence ID: consecutively increasing ID
uint32 seq
#Two-integer timestamp that is expressed as:
# * stamp.secs: seconds (stamp_secs) since epoch
# * stamp.nsecs: nanoseconds since stamp_secs
# time-handling sugar is provided by the client library
time stamp
#Frame this data is associated with
# 0: no frame
# 1: global frame
string frame_id
"""

        order = 0
        migrated_types = []

        valid = False

        def update(self, old_msg, new_msg):
                #No matching field name in old message
                new_msg.header = self.get_new_class('Header')()
                new_msg.axes = old_msg.axes
                new_msg.buttons = old_msg.buttons

Question / concerns / comments

Enter your thoughts on the API and any questions / concerns you have here. Please sign your name. Anything you want to address in the API review should be marked down here before the start of the meeting.

• (Eric) Should this go in sensor_msgs or should their be a new msgs package (joy_msgs or control_msgs or the like)? I feel like a joystick isn't really a sensor, it's a controller.

  • (Chad) I don't believe joy deserves a msgs package of its own. While using wireless controllers we tend to think of them as "separate" from the robot (unlike a laser scanner). I'll bring up the point of our wheelchair that has a joystick on the arm. This one IS a part of the vehicle, and allowed me to make the conceptual jump between something that returns a physical measurement from the robot itself vs something that returns a physical measurement apart from the robot. The joystick is still making a physical measurement (joystick deflection or button presses) and thus could be considered a sensor.

  • (Jack) sensor_msgs is OK with me.

• (Chad) I agree with adding the header. If latency and source timing becomes an issue in someone's teleop, that header sure could be useful in determining origin. Should we be worried or accepting if someone overrides frame_ids for joystick identification instead of the intended tf meaning? Ex: Pilot one publishes on /joy with frame_id "robot_arms" and Pilot two publishes with frame_id "robot_legs".

  • (Jack) I dislike the idea of overloading frame_id (not that we can stop people from doing it if they want). But, I can imagine defining actual tf frame IDs for the use case suggested.

    • (Chad) I also dislike overloading frame_id. I'm also slightly concerned about possible fragmentation involved with robots that are interfaced through /joy with frame_ids of /base_link. This could produce a perception that joy could be a reasonable replacement for twists or wrenches, which they are not for various reasons (not very meaningful units, ambiguity between different vehicles, etc).

    • (Tully) I too agree that overloading the frame_id is bad. "No frame" can just be "frameid_unset" and it's not connected it's not connected, and it's as good as a specific no frame.

• (Jack) It appears that the migration rule generates a zero time stamp in the new Header. I doubt that's legal, but don't know what else to do about it.

  • (Tully) This is not a problem. We use timestamps of 0 already to indicate that the data is untimestamped already. And things like tf just assume that they can take the latest available value.

Meeting agenda

To be filled out by proposer based on comments gathered during API review period

Conclusion

Based on the above feedback I will move the joy msg to sensor_msgs and add the header.